Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP13。

skill 文件描述了「該做什麼、能做到什麼程度」，但真正動手執行遠端操作時，我們選擇讓 AI 呼叫寫死的腳本。

而不是每次都自己臨場組指令。

# scripts/Invoke-ServiceControl.ps1
param(
    [Parameter(Mandatory)][string]$DeviceHost,
    [Parameter(Mandatory)][ValidateSet('start','stop','restart','status')]$Action
)
# 參數檢查、連線、執行、狀態回報都固定在這裡

文件說清楚何時該用這支腳本；真正怎麼連線、怎麼檢查參數，則鎖在腳本裡，不再讓 AI 每次現拼。

這個分工很單純：文件負責說明「什麼時候該用」，腳本負責保證「怎麼穩定執行」。

重複執行、參數合法性檢查、輸出格式、錯誤處理，都不需要每次由 AI 臨場拼湊——腳本寫好之後，這些細節就是固定的、可測試的、可以被 code review 的。

我們也在這一步要求：任務產生的 runtime 輸出，預設一律放在 repository 之外（回到 EP05 提過的那個邊界），並且要求「操作後一定要回讀實際狀態」，而不是看到指令回傳成功碼就直接判定裝置已經完成變更——回傳 0 不代表裝置真的照你想的那樣運作了。

這加起來其實就一句話：文件負責何時該用，腳本負責怎麼穩定執行；回傳成功碼不代表裝置真的變了。

腳本把執行邊界固定下來之後，下一個要解決的問題是：過去累積的經驗、決策、踩過的雷，要怎麼被查得到，卻又不會被誤當成現在的規則？

下一篇來聊「記憶」這件事。